This PR builds on #94372. It does
a similar thing but for the WebAssembly-related helpers. Collectively,
these cut the run time by about 2KB (5%).

The WebAssembly-related module is inserted within
`turbopack-wasm/src/loader.rs`. Similar design questions to #94372
exist. `RUNTIME_ROOT` is added to `contextPrototype` and the JS-code
lives in the `turbopack-wasm` package.

Clarify caching directives non-persistence across deploys.

- [x] reinforce that in serverless deploys, the `use cache` directive
doesn't persist between requests/different instances either

Enable memory eviction by default

If this causes trouble setting
`experimental.turbopackMemoryEviction=false` can disable this feature.

### Fixes #94499


### Summary

The `Instrumentation.onRequestError` type currently exposes the error
parameter as `unknown`, but the docs described it as `Error & { digest:
string }` and the example accessed `err.message` directly.

This updates the docs/example to match the current type and narrows the
caught value before reading `message`.

### Tests:
- `git diff --check`

### What?

Moves 14 insight-kind error pages from
`vercel/front/apps/next-site/content/errors-extra/` into this repo's
`errors/` directory.

### Why?

`nextjs.org`'s sync pipeline already clones `errors/` from canary on
every deploy. `errors-extra/` is meant for in-flight drafts. These pages
have stabilized, so they belong with the framework code they describe.

This unblocks Docs Link Validation in #94496: cross-links from this
repo's API docs (`cookies.mdx`, `headers.mdx`, `use-params.mdx`,
`use-pathname.mdx`, `generate-metadata.mdx`, `generate-viewport.mdx`,
etc.) to `/docs/messages/blocking-prerender-*` now resolve.

### How?

Copied each `.mdx` verbatim. No content changes. Frontmatter (`kind:
insight`) routes them through the FixOption renderer. Follow-up PR in
`vercel/front` will remove the `errors-extra/` copies; until then the
override wins on slug collision but the content is byte-identical.

<!-- NEXT_JS_LLM_PR -->

While force-runtime does opt you into runtime prefetching today (i.e. it
does force) the intended semantic is shifting to convey that the Segment
itself is designed for and makes sense (i.e. cost / performance
tradeoff) to runtime prefetch. In the future segments that may be
runtime prefetched might not be for various optimization reasons. We
therefore are renaming the option from force-runtime to allow-runtime.
In the future if we change allow-runtime to sometimes not runtime
prefetch we can always ship a new force-runtime as a codemod option that
recovers the current behavior.

This wording also better demonstrates why this is a feature of the
Segment and not say an option on the link like `<Link
prefetch="force-runtime" />`.

…ult (#94577)

This PR takes the arena introduced in
#94296 and uses it! It's large but
shouldn't change functionality beyond the use of the arena. Some syntax
related to pattern-matching had to change because `bumpalo`'s `Box`
doesn't support the same pattern matching that the standard library's
`Box` does but the code should be equivalent.

`bumpalo`'s `Bump` type implements `Send` but not `Sync`, to allow us to
pass a `Bump` into async-methods we wrap it in `ThreadLocal` (see
https://docs.rs/thread_local/latest/thread_local/). `ThreadLocal`
implements `Sync` by creating a new bumpalo allocator for each thread.
We've tried to minimise the usage of `ThreadLocal` to just where it was
needed. The downside of `ThreadLocal` is that we may find ourselves
allocating memory for multiple arenas instead of just one. This is more
time allocating if there are multiple threads compared to one shared
allocation, however, it still appears to be a performance improvement
over individually allocating memory for each `JSValue`

---------

Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>